Interdependent Task Management

ABSTRACT

An illustrative embodiment of a computer-implemented process for interdependent task management selects a task from an execution task dependency chain to form a selected task, wherein a type selected from a set of types including “forAll,” “runOnce” and none is associated with the selected task and determines whether there is a “forAll” task. Responsive to a determination that there is no “forAll” task, determines whether there is a “runOnce” task and responsive to a determination that there is a “runOnce” task further determines whether there is a semaphore for the selected task. Responsive to a determination that there is a semaphore for the selected task, the computer-implemented process determines whether the semaphore is “on” for the selected task and responsive to a determination that the semaphore is “on,” sets the semaphore “off” and executes the selected task.

PRIORITY CLAIM

The present application is a continuation of and claims priority fromU.S. patent application Ser. No. 12/912,141, filed on Oct. 26, 2010,titled “Interdependent Task Management,” which claims benefit ofpriority under 35 USC §120 and §365 to the previously filed CanadianPatent Application No. 2961306 entitled, “Interdependent TaskManagement” with a priority date of Jan. 28, 2010. The content of bothapplications are incorporated by reference herein.

BACKGROUND

1. Technical Field

This disclosure relates generally to configuration and buildenvironments in a data processing system and more specifically tointerdependent task management for configuration and build environmentsin data processing systems.

2. Description of the Related Art

A defined build process is a required overhead task that ensuressoftware in a development project is repeatedly built in the same mannereach time a build is executed. As the build process becomes more complexdue to scale of additional tasks or combinations of tasks there is anincreased need to achieve standardization. Standardization requireseffective management of the process and therefore the sequencing ofoperations.

An effectively defined and managed build process is an essential part ofany development cycle. Typically an effectively managed build processremoves many issues related to build and configuration operations thatmay lead to increased cost in the form of project time and money. Atypical tool used by developers for build process management is a toolcalled Ant. Ant is a platform-independent scripting tool. Ant enables asoftware developer to construct build scripts used to automate the buildor configuration process for a configuration project. Ant is a projectthat is managed by and available by download from the Apache SoftwareFoundation as part of the Jakarta project.

A configuration project, for example build automation, consists ofmultiple tasks and prerequisite tasks in a predetermined sequence. Arequirement is that the project should be able to run in either of twomodes. In a first mode the entire project is executed to build up theenvironment and is referred to as the build mode. In a second mode, onlyone or more of the tasks are executed to configure certain portions ofthe already built environment and is referred to as the configure mode.

For example, in the project prerequisite task 1 is an environment setupgeneral task. Prerequisite task 1 is therefore required by each singletask. Prerequisite task 1 may also contain subtasks similar toprerequisite task 2 or prerequisite task 3, and is required to beexecuted only once per execution, in either build mode or configuremode.

Certain tasks, such as a prerequisite task 2 and a prerequisite task 3are required by more than one task. These prerequisite tasks can onlyinvoked once per execution cycle, in either of the build mode orconfiguration mode. Prerequisite task 2 is a time-consuming task.Invoking prerequisite task 2 more than once means a performance loss.Prerequisite task 3 is a task such as decrypting a password. Invokingprerequisite task 3 more than once per cycle means a functional error. Adifficulty arises when defining a dependency relationship to enableflexible execution of the project in either of the two modes, whilemeeting the requirement of running certain tasks only once perexecution.

The Ant build tool provides a keyword of “depends’ to solve part of theinter-dependency issue, but not a complete solution. Ant uses thekeyword ‘depends” to describe the dependency relationship and the parenttasks are executed before the depending ones.

For example, using ANT, in a first case, explicitly declares eachdependency relationship as the following: Task 1 (default task) dependsPrereq1, Prereq3; Task 2 depends Prereq1, Prereq2; Task 3 dependsPrereq1, Prereq2; . . . Task n depends Prereq1, Prereq3, Prereqn. Whenrunning in the build mode, Prereq1, Prereq2 and Prereq3 are executedrepeatedly. Using Ant, in a second case, declare Prereq1 for the defaulttask only Task 1 (default task) depends Prereq1, Prereq3; Task 2 dependsPrereq2; Task 3 depends Prereq2; . . . Task n depends Prereq3, Prereqn.The second case solves the problem for Prereq1 in only the build mode. APrereq2 and Prereq3 problem still exists. However a new problem isencountered, because of the change, which is Prereq1 is missing whenrunning the script in configure mode, for instance, Task 2 only.

BRIEF SUMMARY

According to one embodiment, a computer-implemented process forinterdependent task management selects a task from an execution taskdependency chain to form a selected task, wherein a type selected from aset of types including “forAll,” “runOnce” and none is associated withthe selected task and determines whether there is a “forAll” task.Responsive to a determination that there is no “forAll” task, determineswhether there is a “runOnce” task and responsive to a determination thatthere is a “runOnce” task further determines whether there is asemaphore for the selected task. Responsive to a determination thatthere is a semaphore for the selected task, the computer-implementedprocess determines whether the semaphore is “on” for the selected taskand responsive to a determination that the semaphore is “on,” sets thesemaphore “off” and executes the selected task.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following brief description, taken in conjunction with theaccompanying drawings and detailed description, wherein like referencenumerals represent like parts.

FIG. 1 is a block diagram of an exemplary data processing systemoperable for various embodiments of the disclosure;

FIG. 2 is a block diagram of a task control system, in accordance withvarious embodiments of the disclosure;

FIG. 3 is a block diagram of an interdependent task relationship in atask control system of FIG. 2, in accordance with one embodiment of thedisclosure;

FIG. 4 is a flowchart of an interdependent task management process usingthe task control system of FIG. 2, in accordance with one embodiment ofthe disclosure.

DETAILED DESCRIPTION

Although an illustrative implementation of one or more embodiments isprovided below, the disclosed systems and/or methods may be implementedusing any number of techniques. This disclosure should in no way belimited to the illustrative implementations, drawings, and techniquesillustrated below, including the exemplary designs and implementationsillustrated and described herein, but may be modified within the scopeof the appended claims along with their full scope of equivalents.

As will be appreciated by one skilled in the art, the present disclosuremay be embodied as a system, method or computer program product.Accordingly, the present disclosure may take the form of an entirelyhardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects that may all generally bereferred to herein as a “circuit,” “module,” or “system.” Furthermore,the present invention may take the form of a computer program producttangibly embodied in any medium of expression with computer usableprogram code embodied in the medium.

Computer program code for carrying out operations of the presentdisclosure may be written in any combination of one or more programminglanguages, including an object oriented programming language such asJava™, Smalltalk, C++, or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. Java and all Java-based trademarks and logos aretrademarks of Sun Microsystems, Inc., in the United States, othercountries or both. The program code may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).

The present disclosure is described below with reference to flowchartillustrations and/or block diagrams of methods, apparatus, systems, andcomputer program products according to embodiments of the invention. Itwill be understood that each block of the flowchart illustrations and/orblock diagrams, and combinations of blocks in the flowchartillustrations and/or block diagrams, can be implemented by computerprogram instructions.

These computer program instructions may be provided to a processor of ageneral purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions, which execute via the processor of the computer orother programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer program instructions may also bestored in a computer readable medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide processes for implementing the functions/actsspecified in the flowchart and/or block diagram block or blocks.

Turning now to FIG. 1 a block diagram of an exemplary data processingsystem operable for various embodiments of the disclosure is presented.In this illustrative example, data processing system 100 includescommunications fabric 102, which provides communications betweenprocessor unit 104, memory 106, persistent storage 108, communicationsunit 110, input/output (I/O) unit 112, and display 114.

Processor unit 104 serves to execute instructions for software that maybe loaded into memory 106. Processor unit 104 may be a set of one ormore processors or may be a multi-processor core, depending on theparticular implementation. Further, processor unit 104 may beimplemented using one or more heterogeneous processor systems in which amain processor is present with secondary processors on a single chip. Asanother illustrative example, processor unit 104 may be a symmetricmulti-processor system containing multiple processors of the same type.

Memory 106 and persistent storage 108 are examples of storage devices116. A storage device is any piece of hardware that is capable ofstoring information, such as, for example without limitation, data,program code in functional form, and/or other suitable informationeither on a temporary basis and/or a permanent basis. Memory 106, inthese examples, may be, for example, a random access memory or any othersuitable volatile or non-volatile storage device. Persistent storage 108may take various forms depending on the particular implementation. Forexample, persistent storage 108 may contain one or more components ordevices. For example, persistent storage 108 may be a hard drive, aflash memory, a rewritable optical disk, a rewritable magnetic tape, orsome combination of the above. The media used by persistent storage 108also may be removable. For example, a removable hard drive may be usedfor persistent storage 108.

Communications unit 110, in these examples, provides for communicationswith other data processing systems or devices. In these examples,communications unit 110 is a network interface card. Communications unit110 may provide communications through the use of either or bothphysical and wireless communications links.

Input/output unit 112 allows for input and output of data with otherdevices that may be connected to data processing system 100. Forexample, input/output unit 112 may provide a connection for user inputthrough a keyboard, a mouse, and/or some other suitable input device.Further, input/output unit 112 may send output to a printer. Display 114provides a mechanism to display information to a user.

Instructions for the operating system, applications and/or programs maybe located in storage devices 116, which are in communication withprocessor unit 104 through communications fabric 102. In theseillustrative examples the instructions are in a functional form onpersistent storage 108. These instructions may be loaded into memory 106for execution by processor unit 104. The processes of the differentembodiments may be performed by processor unit 104 usingcomputer-implemented instructions, which may be located in a memory,such as memory 106.

These instructions are referred to as program code, computer usableprogram code, or computer readable program code that may be read andexecuted by a processor in processor unit 104. The program code in thedifferent embodiments may be embodied on different physical or tangiblecomputer readable media, such as memory 106 or persistent storage 108.

Program code 118 is located in a functional form on computer readablemedia 120 that is selectively removable and may be loaded onto ortransferred to data processing system 100 for execution by processorunit 104. Program code 118 and computer readable media 120 form computerprogram product 122 in these examples. In one example, computer readablemedia 120 may be in a tangible form, such as, for example, an optical ormagnetic disc that is inserted or placed into a drive or other devicethat is part of persistent storage 108 for transfer onto a storagedevice, such as a hard drive that is part of persistent storage 108. Ina tangible form, computer readable media 120 also may take the form of apersistent storage, such as a hard drive, a thumb drive, or a flashmemory that is connected to data processing system 100. The tangibleform of computer readable media 120 is also referred to as computerrecordable storage media. In some instances, computer readable media 120may not be removable.

Alternatively, program code 118 may be transferred to data processingsystem 100 from computer readable media 120 through a communicationslink to communications unit 110 and/or through a connection toinput/output unit 112. The communications link and/or the connection maybe physical or wireless in the illustrative examples. The computerreadable media also may take the form of non-tangible media, such ascommunications links or wireless transmissions containing the programcode.

In some illustrative embodiments, program code 118 may be downloadedover a network to persistent storage 108 from another device or dataprocessing system for use within data processing system 100. Forinstance, program code stored in a computer readable storage medium in aserver data processing system may be downloaded over a network from theserver to data processing system 100. The data processing systemproviding program code 118 may be a server computer, a client computer,or some other device capable of storing and transmitting program code118.

The different components illustrated for data processing system 100 arenot meant to provide architectural limitations to the manner in whichdifferent embodiments may be implemented. The different illustrativeembodiments may be implemented in a data processing system includingcomponents in addition to or in place of those illustrated for dataprocessing system 100. Other components shown in FIG. 1 can be variedfrom the illustrative examples shown. The different embodiments may beimplemented using any hardware device or system capable of executingprogram code. As one example, the data processing system may includeorganic components integrated with inorganic components and/or may becomprised entirely of organic components excluding a human being. Forexample, a storage device may be comprised of an organic semiconductor.

As another example, a storage device in data processing system 100 maybe any hardware apparatus that may store data. Memory 106, persistentstorage 108 and computer readable media 120 are examples of storagedevices in a tangible form.

In another example, a bus system may be used to implement communicationsfabric 102 and may be comprised of one or more buses, such as a systembus or an input/output bus. Of course, the bus system may be implementedusing any suitable type of architecture that provides for a transfer ofdata between different components or devices attached to the bus system.Additionally, a communications unit may include one or more devices usedto transmit and receive data, such as a modem or a network adapter.Further, a memory may be, for example, memory 106 or a cache such asfound in an interface and memory controller hub that may be present incommunications fabric 102.

Using data processing system 100 of FIG. 1 as an example, anillustrative embodiment provides the computer-implemented process storedin memory 106, executed by processor unit 104, for interdependent taskmanagement. Processor unit 104 selects a task from an execution taskdependency chain to form a selected task, wherein a type selected from aset of types including “forAll,” “runOnce” and none is associated withthe selected task and determines whether there is a “forAll” task.Responsive to a determination that there is no “forAll” task, processorunit 104 determines whether there is a “runOnce” task and responsive toa determination that there is a “runOnce” task further determineswhether there is a semaphore for the selected task. Responsive to adetermination that there is a semaphore for the selected task, processorunit 104 further determines whether the semaphore is “on” for theselected task and responsive to a determination that the semaphore is“on,” sets the semaphore “off” and executes the selected task.

In another example, a computer-implemented process, using program code118 stored in memory 106 or as a computer program product 122, forinterdependent task management selects a task from an execution taskdependency chain to form a selected task, wherein a type selected from aset of types including “forAll,” “runOnce” and none is associated withthe selected task and determines whether there is a “forAll” task.Responsive to a determination that there is no “forAll” task, determineswhether there is a “runOnce” task and responsive to a determination thatthere is a “runOnce” task further determines whether there is asemaphore for the selected task. Responsive to a determination thatthere is a semaphore for the selected task, the computer-implementedprocess determines whether the semaphore is “on” for the selected taskand responsive to a determination that the semaphore is “on,” sets thesemaphore “off” and executes the selected task.

In an alternative embodiment, program code 118 containing thecomputer-implemented process may be stored within computer readablemedia 120 as computer program product 122. In another illustrativeembodiment, the process for interdependent task management may beimplemented in an apparatus comprising a communications fabric, a memoryconnected to the communications fabric, wherein the memory containscomputer executable program code, a communications unit connected to thecommunications fabric, an input/output unit connected to thecommunications fabric, a display connected to the communications fabric,and a processor unit connected to the communications fabric. Theprocessor unit of the apparatus executes the computer executable programcode to direct the apparatus to perform the process.

With reference to FIG. 2, a block diagram of a task control system, inaccordance with various embodiments of the disclosure is presented. Taskcontrol system 200 is an example, in an illustrative embodiment, of aproject task management or control system. Task control system 200comprises a number of components including task framework 202, sourcecode 204, and result 206.

Other solutions have taken differing approaches to manage build issues.In one example a tool provided changes in dependency handling in aninteractive development environment. The tool typically focused onlimiting resources to rebuild when changes occur in an interactiveenvironment in order to save build time. In this example, the toolstores component objects in one or more containers and removes redundantobjects based on comparison results. Task control system 200 differsfrom the tool of the example because task control system 200 controlstasks during execution time, semaphore is used to determine if aprerequisite task need to be executed. Task control system 200 does notstore an object being processed nor is there a need to perform acomparison of objects being processed.

In another example a build tool is used to achieve the requirement of“execute dependency tasks per build”, but the tool executes all of thedependency tasks only once.

Task control system 200 differentiates the run-once dependency tasksfrom other tasks that can execute multiple times per build as required.Neither example provide a capability of dynamically adding a dependencyon a general environment setup task for executing the task in either aconfigure mode or a build mode and a capability of ensuring that certainprerequisite tasks are invoked and executed only once in either aconfigure mode or a build mode.

Source code 204 is processed through task framework 202 to produceresult 206. Source code 204 comprises program source code used in abuild, configuration or other process to be managed by task controlsystem 200 using task framework 202. For example, source code 204 in abuild or configuration process is typically provided in the form of ascript but other forms of programming language constructs may be used aswell. In the build or configuration process example, the script includesa sequence of named or identified tasks having a presumed sequence ofprocessing.

Result 206, in the example of a build or configuration script, is amodified build or configuration script that may be executed in a stepwise or a stream manner as required. The modified script, in theexample, includes the use of task control information added duringprocessing by task framework 202.

Task framework 202 comprises a number of supporting components includingparser 208, script modifier 210, semaphore checker 212, semaphoremodifier 214, attribute tags 216, and semaphore generator 218. Taskframework 202 provides a capability to define, parse and understand thedefinition of special prerequisite tasks. The capability also provides amethod to dynamically add a dependency to a defined general environmentsetup task, so that the task will be invoked in either a build or aconfiguration execution mode, and a method to ensure certain tasks areinvoked only once per execution cycle. The capability of task framework202 typically ensures that a general environment setup task will notexecute “run-once” tasks more than once in an execution cycle. Theframework hides the complexity from the script writers, enabling scriptusers to mark special tasks, and allow the process to be managed by theframework.

Parser 208 parses the incoming set of tasks as provided by source code204. In the example of a build script, parser 208 would receive theinput as source code 204 and analyze the syntax and semantics of thecode sequences. Parser 208 may be a typical parser capable of parsing alanguage of source code 204.

Script modifier 210 provides a capability of editing and modifying thecontent of source code 204 received from parser 208. Modificationtypically includes insertion of attribute tags selected from attributestags 216. Typical attribute tags include tags for attribute types suchas “run once,” and “for all.” Special tasks as defined within taskframework 202 introduce an attribute name ‘type.’ A general environmentsetup task will have a type=“forAll,” while a run-once task has anattribute type=“runOnce.” A normal task does not include an attribute‘type’ and is simply processed when encountered.

Semaphore checker 212 provides a capability to monitor the status of asemaphore associated with each task in the parsed set of tasks providedby parser 208. A semaphore is an indicator used to provide a signal toother process. For example, in the illustrative embodiment a semaphoremay have a value or setting of on or off. For example, a setting of oncan be indicated by a “green” value and a setting of off can beindicated by “red” value. The value indicates the status of theassociated task and may be used to determine an action within theprocess. Other values may be used to indicate the setting of thesemaphore. In a simple case such as the task framework requires thesetting of a semaphore is of a binary nature, either on or off. Otheruses may include specific values in a range or set of values dependingupon associated use of the semaphore.

Semaphore modifier 214 provides a capability to modify the setting ofthe semaphore value for an associated task. For example, when asemaphore is currently set to “green” a result of a process operationmay cause the value to be set to “red” indicating a change to “red”status. In this example, the process operation requests semaphoremodifier to perform the change in semaphore value to correctly indicatethe status of the task. Semaphore modifier 214 also changes a newlycreated semaphore associated with a task to a desired value on requestaccording to a process of task framework 202.

Semaphore generator 218 provides a capability to create semaphores fortasks that did not previously have a semaphore. For example, upon adetermination that a task being processed does not have a semaphore, theprocess of task framework 202 would call semaphore generator 218 tocreate a semaphore for the task. Task framework 202 manages theexecution of interdependent tasks according to the task dependenciesusing the associated attribute tags and semaphore values of each task.

With reference to FIG. 3, a block diagram of an interdependent taskrelationship in a task control system of FIG. 2, in accordance with oneembodiment of the disclosure is presented. Interdependent taskrelationship 300 is an example of a set of relationships among tasks asmay be found in a typical configuration process or a build process. Thetasks of interdependent task relationship 300 represent a set of taskshaving defined relationships that include dependencies. The dependenciesprescribe a sequence of execution including execute once for eachexecution cycle, and execute each execution cycle. A further dependencyalso includes execution according to a process type such as aconfiguration process or a build process.

Arrows between selected tasks of task 302, task 304, task 306, and taskn 308 and respective prerequisites of perquisite 310, perquisite 312,perquisite 314, and perquisite n 316 define interdependentrelationships. The interdependent relationships indicate whether a taskrequires a respective prerequisite. The prerequisite may be another taskor other element in the task management process. Task framework 202 ofFIG. 2 defined special tasks, introducing an attribute name ‘type.’ Forexample, perquisite 310 is a general environment setup task of atype=“forAll.” Prerequisite 312 is a task that is required to be runonce per execution cycle and therefore has a type=“runOnce.” Other tasksthat are normal tasks do not include an attribute ‘type.’ A typetherefore may be selected from a set of types including “forAll,”“runOnce” and none and is associated with the selected task. A selectedtask having a type of none is typically found without a type attributebut may be explicitly typed with type=“none” as well.

For example, using an ANT framework for task management, task 302 is adefault task that has a dependency on Prerequisite 314. Task 304 has adependency on prerequisite 312, task 306 has a dependency onprerequisite 312, and task n 308 depends on prerequisite 314 andprerequisite n 316. Further, a type=“forAll” is associated withprerequisite 310, a type=“runOnce” is associated with Prerequisite 314and a type=“runOnce” is associated with prerequisite 312.

Ant provides a capability to load the list of tasks to be executed atexecution time. The list of tasks starts from the task name specified bythe user when in configure mode or starts from the default task namewhen in build mode. Ant may further be used to parse the dependenciesand compute the execution sequence tasks. The enhancements using thedependency attributes of task control system 200 in the illustrativeembodiment of FIG. 2 now identify type=“forAll” task and add adependency from the first task in the execution sequence to the selectedtask being processed task. The mechanism of task framework 202 of FIG. 2also is used to identify tasks having a type=‘runOnce.’ A semaphore flagis created for each of these tasks. The framework also checks thecorresponding semaphore before executing the task, and updates thecorresponding semaphore after the task is executed.

With reference to FIG. 4, a flowchart of an interdependent taskmanagement process using the task control system of FIG. 2, inaccordance with one embodiment of the disclosure is presented. Process400 is an example of a process using the capabilities of task framework202 of task control system 200 of FIG. 2.

Process 400 starts (step 402) and receives source code to form receivedsource code (step 404). Process 400 loads the received source code intoan execution task dependency chain (step 406). The execution taskdependency chain is a prescribed sequence of tasks in which some taskshave a defined dependency upon other tasks. The process of creating theexecution task dependency chain typically includes parsing dependenciesin the source code, computing an execution sequence for tasks to form anexecution task dependency chain, and loading the execution taskdependency chain into a memory for subsequent processing.

Select a task from the execution task dependency chain to form aselected task is performed (step 408). Process 400 determines whetherthere is a “forAll” task (step 410). A “forAll” task is a task that hasa type=“forAll” and applies to all tasks. For example, a “forAll” tasktypically establishes an environment applicable to all other tasks. Whena determination is made that there is a “forAll” task, a “yes” result isobtained. When a determination is made that there is not a “forAll”task, a “no” result is obtained.

When a “yes” result is obtained in step 410, process 400 adds adependency relationship from a first task to an identified “forAll” task(step 412). When a “no” result is obtain in step 410, process 400determines whether there is a “runOnce” task (step 414). A “runOnce”task is a task having a type=“runOnce” task. When a determination ismade that there is a “runOnce” task, a “yes” result is obtained. When adetermination is made that there is not a “runOnce” task, a “no” resultis obtained. A task without a type or with a type=“none” is treated as atask without a type attribute.

When a “no” result is obtained in step 414, execute the selected task isperformed (step 416). Process 400 skips to step 424. When a “yes” resultis obtained in step 414 determine whether there is a semaphore for theselected task (step 418). When a determination is made that there is asemaphore for the selected task, a “yes” result is obtained. When adetermination is made that there is not a semaphore for the selectedtask, a “no” result is obtained. When a “no” result is obtained in step418, process 400 creates a semaphore for the selected task (step 420).Process 400 sets the semaphore for the selected task to “red” or “off”(step 426) executes the selected task (step 416) as before.

When a “yes” result is obtained in step 418, process 400 determineswhether the semaphore is set to “green” (step 422). When a determinationis made that the semaphore is set to “green,” a “yes” result isobtained. When a determination is made that the semaphore is not set to“green” or “on” a “no” result is obtained. When a “yes” result isobtained, process 400 sets the semaphore for the selected task to “red”(step 426) executes the selected task (step 416) as before. When a “no”result is obtained process 400 determines whether there are more tasksto process (step 424). When a determination is made that there are moretasks to process, a “yes” result is obtained. When a determination ismade that there are no more tasks to process, a “no” result is obtained.

When a “yes” result is obtained in step 424, process 400 loops back tostep 414 to continue processing tasks in the execution task dependencychain. Process 400 iterates through the remaining tasks of the executiontask dependency chain to process each task. When a “no” result isobtained in step 424, process 400 terminates (step 428).

Thus the illustrative embodiment defines a computer-implemented processthat provides a capability to define, parse and understand thedefinition of special prerequisite tasks. The capability also provides amethod to dynamically add a dependency to a defined general environmentsetup task, so that the task will be invoked in either a build or aconfiguration execution mode, and a method to ensure certain tasks areinvoked only once per execution cycle. The capability of the taskframework typically ensures that a general environment setup task willnot execute “run-once” tasks more than once in an execution cycle. Thetask framework may be used to typically hide the complexity ofinterdependent task management from the script writers, enabling scriptusers to mark special tasks, and allow the process to be managed by theframework.

Thus is provided, in an illustrative embodiment, a computer-implementedprocess for interdependent task management selects a task from anexecution task dependency chain to form a selected task, wherein a typeselected from a set of types including “forAll,” “runOnce” and none isassociated with the selected task and determines whether there is a“forAll” task. Responsive to a determination that there is no “forAll”task, determines whether there is a “runOnce” task and responsive to adetermination that there is a “runOnce” task further determines whetherthere is a semaphore for the selected task. Responsive to adetermination that there is a semaphore for the selected task, thecomputer-implemented process determines whether the semaphore is “on”for the selected task and responsive to a determination that thesemaphore is “on,” sets the semaphore “off” and executes the selectedtask.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing a specified logical function. It should also be noted that,in some alternative implementations, the functions noted in the blockmight occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

The invention can take the form of an entirely hardware embodiment, anentirely software embodiment or an embodiment containing both hardwareand software elements. In a preferred embodiment, the invention isimplemented in software, which includes but is not limited to firmware,resident software, microcode, and other software media that may berecognized by one skilled in the art.

It is important to note that while the present invention has beendescribed in the context of a fully functioning data processing system,those of ordinary skill in the art will appreciate that the processes ofthe present invention are capable of being distributed in the form of acomputer readable medium of instructions and a variety of forms and thatthe present invention applies equally regardless of the particular typeof signal bearing media actually used to carry out the distribution.Examples of computer readable media include recordable-type media, suchas a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, andtransmission-type media, such as digital and analog communicationslinks, wired or wireless communications links using transmission forms,such as, for example, radio frequency and light wave transmissions. Thecomputer readable media may take the form of coded formats that aredecoded for actual use in a particular data processing system.

A data processing system suitable for storing and/or executing programcode will include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards,displays, pointing devices, etc.) can be coupled to the system eitherdirectly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modems, and Ethernet cards are just a few of thecurrently available types of network adapters.

The description of the present invention has been presented for purposesof illustration and description, and is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the art. Theembodiment was chosen and described in order to best explain theprinciples of the invention, the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

1. A computer-implemented process for interdependent task management,the computer-implemented process comprising: selecting a task from anexecution task dependency chain to form a selected task, wherein a typeselected from a set of types including “forAll,” “runOnce” and none isassociated with the selected task; determining whether there is a“forAll” task; responsive to a determination that there is no “forAll”task, determining whether there is a “runOnce” task; responsive to adetermination that there is a “runOnce” task; determining whether thereis a semaphore for the selected task; responsive to a determination thatthere is a semaphore for the selected task, determining whether thesemaphore is “on” for the selected task; responsive to a determinationthat the semaphore is “on,” setting the semaphore “off;” and executingthe selected task.
 2. The computer-implemented process of claim 1wherein selecting a task from an execution task dependency chain to forma selected task further comprises: receiving a source code to form areceived source code; parsing dependencies in the source code; computingan execution sequence for tasks to form an execution task dependencychain; and loading the execution task dependency chain.
 3. Thecomputer-implemented process of claim 1 wherein responsive to adetermination that there is not a “forAll” task further comprises:adding a dependency relationship from a first task to an identified“forAll” task.
 4. The computer-implemented process of claim 1 whereinresponsive to a determination that there is not a semaphore for theselected task further comprises: creating a semaphore for the selectedtask; setting the semaphore for the selected task “off;” and executingthe selected task.
 5. The computer-implemented process of claim 1wherein responsive to a determination that the semaphore is “off,”further comprises: determining whether there are more tasks; responsiveto a determination that there are more tasks, selecting a task from anexecution task dependency chain to form a selected task; and responsiveto a determination that there are no more tasks, terminating.
 6. Thecomputer-implemented process of claim 3 wherein adding a dependencyrelationship from a first task further comprises: identifying the firsttask in the execution task dependency chain, wherein the execution taskdependency chain starts from one of a task name specified by a user anda default task name.
 7. The computer-implemented process of claim 1wherein responsive to executing the selected task further comprises:determining whether there are more tasks.
 8. A computer program productfor interdependent task management, the computer program productcomprising: a computer recordable-type media containing computerexecutable program code stored thereon, the computer executable programcode comprising: computer executable program code for selecting a taskfrom an execution task dependency chain to form a selected task, whereina type selected from a set of types including “forAll,” “runOnce” andnone is associated with the selected task; computer executable programcode for determining whether there is a “forAll” task; computerexecutable program code responsive to a determination that there is no“forAll” task, for determining whether there is a “runOnce” task;computer executable program code responsive to a determination thatthere is a “runOnce” task; for determining whether there is a semaphorefor the selected task; computer executable program code responsive to adetermination that there is a semaphore for the selected task, fordetermining whether the semaphore is “on” for the selected task;computer executable program code responsive to a determination that thesemaphore is “on,” for setting the semaphore “off;” and computerexecutable program code for executing the selected task.
 9. The computerprogram product of claim 8 wherein computer executable program code forselecting a task from an execution task dependency chain to form aselected task further comprises: computer executable program code forreceiving a source code to form a received source code; computerexecutable program code for parsing dependencies in the source code;computer executable program code for computing an execution sequence fortasks to form an execution task dependency chain; and computerexecutable program code for loading the execution task dependency chain.10. The computer program product of claim 8 wherein computer executableprogram code responsive to a determination that there is not a “forAll”task further comprises: computer executable program code for adding adependency relationship from a first task to an identified “forAll”task.
 11. The computer program product of claim 8 wherein computerexecutable program code responsive to a determination that there is nota semaphore for the selected task further comprises: computer executableprogram code for creating a semaphore for the selected task; computerexecutable program code for setting the semaphore for the selected task“off;” and computer executable program code for executing the selectedtask.
 12. The computer program product of claim 8 wherein computerexecutable program code responsive to a determination that the semaphoreis “off” further comprises: computer executable program code fordetermining whether there are more tasks; computer executable programcode responsive to a determination that there are more tasks, forselecting a task from an execution task dependency chain to form aselected task; and computer executable program code responsive to adetermination that there are no more tasks, for terminating.
 13. Thecomputer program product of claim 10 wherein computer executable programcode for adding a dependency relationship from a first task furthercomprises: computer executable program code for identifying the firsttask in the execution task dependency chain, wherein the execution taskdependency chain starts from one of a task name specified by a user anda default task name.
 14. The computer program product of claim 1 whereincomputer executable program code responsive to executing the selectedtask further comprises: computer executable program code for determiningwhether there are more tasks.
 15. An apparatus for interdependent taskmanagement, the apparatus comprising: a communications fabric; a memoryconnected to the communications fabric, wherein the memory containscomputer executable program code; a communications unit connected to thecommunications fabric; an input/output unit connected to thecommunications fabric; a display connected to the communications fabric;and a processor unit connected to the communications fabric, wherein theprocessor unit executes the computer executable program code to directthe apparatus to: select a task from an execution task dependency chainto form a selected task, wherein a type selected from a set of typesincluding “forAll,” “runOnce” and none is associated with the selectedtask; determine whether there is a “forAll” task; responsive to adetermination that there is no “forAll” task, determine whether there isa “runOnce” task; responsive to a determination that there is a“runOnce” task; determine whether there is a semaphore for the selectedtask; responsive to a determination that there is a semaphore for theselected task, determine whether the semaphore is “on” for the selectedtask; responsive to a determination that the semaphore is “on,” set thesemaphore “off;” and execute the selected task.
 16. The apparatus ofclaim 15 wherein the processor unit executes the computer executableprogram code to select a task from an execution task dependency chain toform a selected task further directs the apparatus to: receive a sourcecode to form a received source code; parse dependencies in the sourcecode; compute an execution sequence for tasks to form an execution taskdependency chain; and load the execution task dependency chain.
 17. Theapparatus of claim 15 wherein the processor unit executes the computerexecutable program code responsive to a determination that there is nota “forAll” task to further direct the apparatus to: add a dependencyrelationship from a first task to an identified “forAll” task.
 18. Theapparatus of claim 15 wherein the processor unit executes the computerexecutable program code responsive to a determination that there is nota semaphore for the selected task to further direct the apparatus to:create a semaphore for the selected task; set the semaphore for theselected task “off;” and execute the selected task.
 19. The apparatus ofclaim 15 wherein the processor unit executes the computer executableprogram code responsive to a determination that the semaphore is “off”to further direct the apparatus to: determine whether there are moretasks; responsive to a determination that there are more tasks, select atask from an execution task dependency chain to form a selected task;and responsive to a determination that there are no more tasks,terminate.
 20. The apparatus of claim 17 wherein the processor unitexecutes the computer executable program code to add a dependencyrelationship from a first task further directs the apparatus to:identify the first task in the execution task dependency chain, whereinthe execution task dependency chain starts from one of a task namespecified by a user and a default task name.